In the current data communication network, the QoS function is an important and commonly-used network function either in a Local Area Network (LAN), a metropolitan area network or a wide area network. The QoS function of a network means that the network provides different QoS guarantees aiming at different requirements of various service applications, such as bandwidth, packet loss rate, delay and delay jitter, so as to implement an integrated network which simultaneously carries various services like data, voice and video. FIG. 1 is a diagram of a service traffic processing flow in which a network device implements the QoS function; as shown in FIG. 1, the QoS function of the network mainly includes the following four functions: the first is a flow classifying and marking function; the flow is a group of data packets with the same characteristic; flow classifying is classifying service traffics entering the network according to a certain flow classifying rule (e.g. some field values based on a port or a packet); flow marking is setting a Class or Service (CoS) and a priority mark in the network for a service packet after flow classifying, so as to distinguish QoS of different service flows; the second is a traffic metering, colouring and policing function; this function is, after completing the flow classifying and the flow marking, performing rate metering to the service flow, and performing colouring and rate limiting to the packet entering according to an arrival rate of traffic, a configured Committed Information Rate (CIR) and a Peak Information Rate (PIR). Specifically speaking, packet colouring and rate limiting usually use a Two rate Three Colour Marker (TrTCM) algorithm which is specified by the standard RFC2698 of the Internet Engineering Task Force (IETF); the algorithm implements the rate limiting of the service flow by marking the packet not exceeding the CIR as green, marking the packet exceeding the CIR but not exceeding the PIR as yellow, marking the packet exceeding the PIR as red, and dropping the red packet; the third is a queue congestion managing and queue scheduling function; the service traffic after traffic metering, colouring and policing will enter buffer queues with different classes, and this process is called queuing; queue congestion managing is monitoring queue buffer, which is specifically foreseeing and avoiding the occurrence of congestion via Tail Drop (TD), Random Early Detection (RED) or Weighted Random Early Detection (WRED) and other packet dropping ways; queue scheduling is selecting the packets from the buffer queues representing different CoS and putting these packets in output queue in a particular order, namely scheduling aiming at a de-queuing order of the packets buffered in different queues, so as to avoid the congestion to the greatest extent and satisfy the de-queuing of the service traffic with high priority; the commonly used queue scheduling algorithms include a Strict Priority Queue (SPQ) scheduling algorithm, a Weighted Fair Queue (WFQ) scheduling algorithm, a Deficit Weighted Round Robin (DWRR) scheduling algorithm, and so on; the fourth is a traffic shaping and priority overriding function; traffic shaping is generally implemented to the traffic after queue scheduling through a leaky bucket mechanism; the traffic shaping implements a traffic rate limiting function as the traffic policing, and the difference between them is that the traffic shaping does not directly drop the traffics exceeding a limited rate as the traffic policing, but buffers these traffics, and sends out the buffered packets at the appropriate time, so that the traffic may maintain a quite uniform rate to contribute to reducing the probability of packet loss caused by the bursts of traffic at a downstream network node. Before the service traffic is sent out from an egress port, except the traffic shaping is completed, the priority of the packet may also be overridden to influence the QoS processing of the downstream network node.
The QoS function of the network may be used for implementing both single-layer QoS and Hierarchical QoS (HQoS). The single-layer QoS may only perform service bandwidth control and queue scheduling based on the port, but cannot perform traffic management for different users and services with different CoS in the different users at the same time, while the HQoS may implement that. FIG. 2 is a diagram of a hierarchical traffic management model of the HQoS; as shown in FIG. 2, the HQoS in this example implements four-level traffic management, namely a port level, a user group level, a user level and a service level. The HQoS implements bandwidth control, queue scheduling and other QoS functions by layering, and may perform fine control to bandwidth allocation of each layer in a complicated networking and hierarchical service model, thereby achieving the purpose of guaranteeing the QoS of an end-to-end service. FIG. 3 is a comparison diagram of a single-layer QoS scheduling mechanism and an HQoS scheduling mechanism; as shown in FIG. 3, single-layer QoS scheduling means that the whole QoS processing uses only one scheduler and may complete only one layer of QoS scheduling; HQoS scheduling means that the whole QoS processing uses multiple schedulers (the HQoS in FIG. 3 uses three schedulers), and may complete multiple layers of QoS scheduling (the HQoS in FIG. 3 completes two layers of QoS scheduling). Based on the obvious technical advantages of the HQoS relative to the single-layer QoS, the TR-101 (the second edition) standard published by the international standards developing organization Broadband Forum (BBF) in July 2011 clearly puts forward that the network device is required to support the HQoS capability, and now there are more and more commercial network devices able to support the HQoS capability currently.
With a Software Defined Network (SDN) concept presented and the development of applications of the concept, an OpenFlow technology as the core technology of the SDN is in a stage of rapid development; at present, an OpenFlow network built through the OpenFlow technology has been used more and more in the actual production and life. The OpenFlow network adopts an architecture with a control plane and a forwarding plane (also called a data plane) separate; FIG. 4 is a diagram of an architecture of the OpenFlow network components. As shown in FIG. 4, the control plane of the OpenFlow network is realized by an OpenFlow controller, wherein the OpenFlow controller is a device with strong computing capability, and the specific device type may be a personal computer, a server, or a server cluster and the like; the forwarding plane of the OpenFlow network is realized by an OpenFlow switch, the OpenFlow switch is a device with strong switching capability, and the specific device type may be a network device equipped with multiple network ports and performing packet processing and forwarding based on a flow table; an OpenFlow interface between the OpenFlow controller and the OpenFlow switch runs an OpenFlow protocol, wherein the protocol is developed and modified by the international standards developing organization Open Networking Foundation (ONF).
The OpenFlow switch specification 1.3.2 released by the ONF in April 2013 specifies an OpenFlow protocol flow and a packet processing flow in the OpenFlow switch, which include a method used by the OpenFlow protocol and the OpenFlow switch to implement the QoS function. FIG. 5 is a diagram of a packet processing flow in which the OpenFlow switch implements the QoS function; as shown in FIG. 5, first the flow table is matched for the packet entering the OpenFlow switch from an ingress port, wherein the flow table is issued, by the OpenFlow controller, to the OpenFlow switch through the OpenFlow protocol. FIG. 6 is a format diagram of the OpenFlow flow table; as shown in FIG. 6, the flow table may include multiple flow table entries, and all match fields in each flow table entry may be any fields (e.g. an address field, a user Identity (ID) field, a service priority field, and so on) in a packet header. Next, for the packet with the successfully matched flow table, an instruction in the corresponding flow table entry is executed. There is an instruction “Meter meter_id” available for calling the corresponding meter, wherein the meter may implement the traffic metering, colouring and policing function; all the meters are configured in a meter table, and the meter table is issued, by the OpenFlow controller, to the OpenFlow switch through the OpenFlow protocol. FIG. 7 is a format diagram of an OpenFlow meter table; as shown in FIG. 7, there may be multiple meters included in the meter table, and meter bands in each meter are used for configuring the CIR/PIR and a colouring rule of the meter. The packet processing flow of the OpenFlow switch may include multiple levels of flow table, an each level of flow table may call the meter; another instruction “Write-Actions action” may be used for adding new actions into an action set; there is an action “Set-Queue queue_id” available for adding the packet into the corresponding queue; each queue may implement the traffic metering, colouring and policing function, and multiple queues may also implement a queue scheduling function; configuration parameters of the queue are issued, by the OpenFlow controller, to the OpenFlow switch through an OF-Config protocol (which is a specified configuration protocol different from the OpenFlow protocol). As an action in the action set, a queuing and the queue scheduling function and other functions implemented by the Set-Queue action are executed at the end of the packet processing flow of the OpenFlow switch.
To sum up, as stipulated in the current OpenFlow switch specification, the traffic metering, colouring and policing function in the QoS function may be executed as the instruction during the packet processing flow of the OpenFlow switch, but the queuing and queue scheduling function may only be executed as the action at the end of the packet processing flow of the OpenFlow switch, which makes the OpenFlow switch be only able to implement single-layer queue scheduling based on the port instead of multi-layer queue scheduling required by the HQoS.
Aiming at the above problem that the OpenFlow switch cannot implement the HQoS, an effective solution has not been presented yet.